<?xml version='1.0'?><!DOCTYPE html PUBLIC><html xmlns='http://www.w3.org/1999/xhtml'>
  <head>
    <title>jMock - Comparing jMock and EasyMock</title>
    <link href='/jmock.css' title='Navigation View' rel='stylesheet' type='text/css' media='screen' />
    <link href='/print.css' title='Print Preview' rel='alternate stylesheet' type='text/css' media='screen' />
    <link href='/print.css' rel='stylesheet' type='text/css' media='print' />
    <meta content='application/xhtml+xml; charset=UTF-8' http-equiv='Content-Type' />
  </head>

  <body>
    <div id='banner'>
      <a href='/index.html'><img src='/logo.gif' id='logo' alt='jMock' /></a>
    </div>

    

    
      <div class='Content2Column' id='center'>
        <div id='content'>
          <h1 class='FirstChild'>Comparing jMock and EasyMock</h1><p>Like jMock, <a href='http://www.easymock.org'>EasyMock</a><span class='LinkFootnoteRef'><sup>1</sup></span> is a dynamic
mock object library for Java. What are the main differences between jMock and
EasyMock?</p><h2>jMock uses strings to identify methods</h2><p>EasyMock uses actual method calls to define expectations. EasyMock
therefore works with an IDE's code completion and refactoring tools better
than jMock.</p><div class='Source EasyMock'>
<pre>mock.method1( a );
mockControl.playback();</pre>
</div><div class='Source JMock'>
<pre>mock.expects(once()).method("method1").with( eq(a) );</pre>

<p>We have found that the use of strings in jMock is not a huge
disadvantage, especially if you use an IDE that can apply refactorings to
names in string constants. Often when doing TDD, the method named in an
expectation will not yet be defined in any interface, and so code completion
cannot be used.  We have found that the <a href='yoga.html'>flexibility</a><span class='LinkFootnoteRef'><sup>2</sup></span>
allowed by the jMock API is better at reducing the work of refactoring than
the use of direct method calls.</p>
</div><h2>jMock forces you to precisely specify required behaviour.</h2><p>By default, EasyMock tests actual arguments for equality to expected
arguments using the <code>equals</code> method. This can overspecify expected
behaviour and make tests brittle. Sometimes you want to ignore an argument or
want looser constraints upon an argument's value. EasyMock lets you change
the way that arguments are matched on a call-by-call basis, but the syntax is
awkward and same matcher applies to <em>all</em> arguments. There isn't a way
to specify a different matcher for different arguments to the same call.</p><div class='Source EasyMock'>
<pre>mock.method1( a );
mock.method2( b1, b2 ); // cannot specify that we don't care about argument b2
mockControl.setReturnValue( method2Result );
mockControl.playback();</pre>
</div><p>In contrast, jMock forces the user to specify exactly how each actual
argument is matched against expectations. This means that expectations are
more verbose but precisely and clearly specify the expected behaviour of the
object. By precisely specifying expected behaviour you get <a href='yoga.html'>flexible tests</a><span class='LinkFootnoteRef'><sup>3</sup></span> that break only when the actual behaviour
is different from expected behaviour, and do not break when you make
unrelated changes to application code.</p><div class='Source JMock'>
<pre>mock.expects(once()).method("method1").with( eq(a) );
mock.expects(once()).method("method1").with( same(b1), ANYTHING )
    .will(returnValue(method2Result));</pre>
</div><h2>jMock tests read as specifications</h2><p>jMock is a design tool not a testing tool. jMock's API is designed so that
tests express the design intent of the programmer as clearly as possible and
can later be read as specifications. In EasyMock's "record/playback" API,
expectations are normal method invocations that do not read as specifications
and constraints upon those invocations must be specified with separate API
calls that duplicate information about the expected call and are harder to
read than jMock's expectations.</p><h2>jMock expectations require more typing</h2><p>The result of the previous two design goals is that jMock requires that
the programmer writing a test be very explicit about what is and isn't
expected. The "call-chain" API style makes expectations longer than
EasyMock's terse "record/playback" style. We were surprised, however, to find
that our users <em>prefer</em> all the extra typing that jMock forced them to
do because the result helps them quickly understand what tests are
specifying.</p><h2>jMock can stub methods with side effects</h2><p>EasyMock only stubs methods that return values or throw exceptions. jMock
lets you write <a href='custom-stubs.html'>custom stubs</a><span class='LinkFootnoteRef'><sup>4</sup></span> that can call
back into the tested object or perform other side effects.</p><div class='Source jMock'>
<pre>mock.expects(once()).method("collectIntoList").with( isA(List.class) )
    .will(addListElement(element));</pre>
</div><h2>jMock gives you fine control over invocation order</h2><p>EasyMock lets the programmer specify that calls to a mock must occur in
order, or occur in any order. There is no way to specify that call
<var>a</var> should occur after call <var>b</var> but in any order compared
to call <var>c</var>. There is no way to test the order of calls to different
mock objects.</p><p>jMock lets the programmer specify partial ordering of invocations and
specify the order of invocations on different mock objects.</p><h2>jMock's API syntax is extensible</h2><p>EasyMock can be extended in a few ways by the user. However extensions do
not cleanly integrate with the rest of the framework and extension points are
quite limited. For example, you cannot extend the way that EasyMock stubs
calls.</p><p>User extensions to jMock are used in exactly the same way as the built-in
jMock constructs. This makes it easier to read tests, because unimportant
details (whether a constraint is or is not an extension) are kept out of the
code of test methods. jMock lets the user extend more aspects of the
framework's behaviour.</p><h2>jMock automatically verifies mock objects</h2><p>jMock automatically verifies mock objects at the end of the test. It is
easy to forget to verify all your mock objects and this can hide test
failures.  However, this means that...</p><h2>jMock uses its own test case class</h2><p>To use jMock your test cases must extend
<a href='/docs/javadoc/org/jmock/MockObjectTestCase.html'>MockObjectTestCase</a><span class='LinkFootnoteRef'><sup>5</sup></span>.
This class performs automatic verification and provides the syntactic sugar that
makes jMock tests easy to read.
</p>
        <div class='LinkFootnotes'><p class='LinkFootnotesHeader'>Links:</p><p>1. <a href='http://www.easymock.org'>http://www.easymock.org</a></p><p>2. <a href='http://www.jmock.org/yoga.html'>http://www.jmock.org/yoga.html</a></p><p>3. <a href='http://www.jmock.org/yoga.html'>http://www.jmock.org/yoga.html</a></p><p>4. <a href='http://www.jmock.org/custom-stubs.html'>http://www.jmock.org/custom-stubs.html</a></p><p>5. <a href='http://www.jmock.org/docs/javadoc/org/jmock/MockObjectTestCase.html'>http://www.jmock.org/docs/javadoc/org/jmock/MockObjectTestCase.html</a></p></div></div>
	    <div class='Meta'>
	      <p><a href='http://cvs.jmock.codehaus.org/jmock/website/content/easymock-comparison.html'>Document History</a></p>
	    </div>
      </div>
    

    <div class='SidePanel' id='left'>
      <div class='MenuGroup'>
        <h1><a href='/download.html'>Software</a></h1>
        <ul>
          <li><a href='/download.html'>Download</a></li>
          <li><a href='/repository.html'>Anonymous CVS Access</a></li>
          <li><a href='/license.html'>Project License</a></li>
          <li><a href='/CHANGELOG'>Change Log</a></li>
        </ul>
      </div>

      <div class='MenuGroup'>
        <h1><a href='/docs.html'>Documentation...</a></h1>
        <ul>
          <li><a href='/getting-started.html'>Getting Started</a></li>
          <!-- <li><a href="">Frequently Asked Questions</a></li> -->
          <li><a href='/docs/javadoc/index.html' target='jmock-javadoc'>JavaDocs</a></li>
          <li><a href='http://www.mockobjects.com'>More about Mock Objects</a></li>
        </ul>
      </div>

      <div class='MenuGroup'>
        <h1>User Support</h1>
        <ul>
          <li><a href='/mailing-lists.html'>Mailing Lists</a></li>
          <li><a href='http://jira.codehaus.org/secure/BrowseProject.jspa?id=10336'>Issue Tracker</a></li>
          <li><a href='/news-rss2.xml'>News Feed (RSS 2.0)</a></li>
        </ul>
      </div>

      <div class='MenuGroup'>
        <h1><a href='/development.html'>Development...</a></h1>
        <ul>
          <li><a href='/how-to-contribute.html'>How to Contribute</a></li>
          <li><a href='/team.html'>Development Team</a></li>
        </ul>
      </div>

      <div class='MenuGroup'>
        <h1>Related Sites</h1>
        <ul>
          <li><a href='http://www.mockobjects.com'>Mock Objects</a></li>
          <li><a href='http://www.junit.org'>JUnit</a></li>
          <li><a href='http://www.nmock.org'>nMock</a></li>
          <li><a href='http://www.codehaus.org'>Project hosted by Codehaus</a></li>
        </ul>
      </div>
    </div>

    
  </body>
</html>